This invention relates to data networks and, more particularly, to an ability to perform distributed object rendering on a data network. Specifically, a plurality of collaborative proxy servers perform distributed object rendering so that object contents can be displayed on or consumed by various kinds of client devices, based on their respective device capabilities and specifications.
As the Internet becomes ever more popular, more non-personal computer (PC) devices, such as so-called smart phones and PDAs (personal digital assistants), are connected to the Internet, either by wired or wireless connections. The Internet is becoming the so-called pervasive computing environment, where various kinds of information appliances/devices, as well as PCs and other server computers, are all connected. In such a pervasive computing environment it is expected that the individual appliances/devices will have different computing powers and display capabilities. For example, some devices may be capable of displaying color images while others can only display black-and-white images. Also, some devices may have large, easily viewed displays while others may have only a relatively much smaller display. It can thus be appreciated that in such a pervasive computing environment the same information objects may have to be rendered in different forms or resolutions according to different device display specifications. Various techniques have been developed to represent information in various resolutions. In xe2x80x9cA Framework for Optimization of a Multiresolution Remote Image Retrieval Systemxe2x80x9d by A. Ortega et al., Proceedings of IEEE InforCom, 1994, a system was disclosed to transmit images and video in multiple resolutions. In xe2x80x9cThe JPEG Still Picture Compression Standard,xe2x80x9d by G. Wallace, IEEE Transactions on Consumer Electronics, vol. 38, no. 1, February 1992, the JPEG image compression standard was described to represent images in multiple different resolutions.
The rendering of an object into different forms or resolutions can be performed in different locations. One possible location is within the content servers. However, the content servers may easily become overloaded, especially with a large number of different client requests all coming to the same content servers. Another possible location to render the object is within a client machine which will actually consume the object. However, this is an undesirable solution since many typical client machines tend to be too limited in computing power to perform the necessary rendering function.
Alternatively, the rendering can be done by one or more proxy servers, which are positioned in the data network between the content servers and the client devices. In this scenario the device-specific information can be piggybacked on the meta-information associated with the objects, and the proxy server can perform object rendering according to the meta-information. Once the object rendering is performed by the proxy server the result can be cached (stored) at the proxy server. In this case any subsequent requests for the same object, from the same kind of device, can be served directly from the stored copy in proxy server cache. As a result, the repeated rendering of the object for the same kind of device can be avoided. In order to improve the response time, many PC servers, such as the IBM NETFINITY servers, are being deployed in the Internet as a network of proxy servers (IBM and NETFINITY are both registered trademarks of the International Business Machines Corporation). These proxy servers can work collaboratively in object rendering and caching.
For example, in the above-referenced commonly assigned U.S. Patent Application by B. Hailpern et al., entitled xe2x80x9cCollaborative Server Processing of Content and Meta-Information with Application to Virus Checking in a Server Network,xe2x80x9d a method was disclosed to perform virus checking based on the meta-information on the proxy network by choosing one proxy server. This approach discloses a method to perform certain computations on the object based on the meta-information by one of the proxies in the network. No specific attention was paid to the aspect of caching the objects after the computation. Also, the computation is done completely by the chosen proxy server, and is not done by more than one proxy server in a distributed way.
In the above-referenced commonly assigned U.S. Patent Application by J. Beurket et al., entitled xe2x80x9cMethod for Collaborative Transformation and Caching of Web Objects in a Proxy Network,xe2x80x9d a method was proposed to locate one or more specialized proxies to perform the transformation and caching. Once the transformation/rendering is done and cached, all subsequent requests for the desired resolution are served by these specialized transformational proxies. In this approach the caching and rendering of an object is completely done on the same specialized proxies, and the rendering of objects is not readily performed in different stages or collaboratively by more than one different proxies in a distributed way.
In an approach described by A. Fox, entitled xe2x80x9cAdapting to Network and Client Variation Using Infrastructural Proxies: Lessons and Perspective,xe2x80x9d IEEE Personal Communications, pp. 10-19, August 1998, a method was disclosed to perform datatype-specific distillation on a cluster of proxies. Object rendering and caching are all performed by the specific cluster of proxies. A centralized manager is used to perform load balancing among the proxies in the cluster. A drawback of this approach is that object rendering and caching is completely done on the same cluster of proxies, and is not done in a distributed way. Other proxies in the network, but not in the same cluster, cannot participate in some of the stages in the object rendering process.
In view of the foregoing, it can be appreciated that there exists a need for a collaborative proxy system that can deploy object rendering in a distributed fashion. Prior to this invention, this need was not fulfilled.
It is a first object and advantage of this invention to provide a collaborative proxy system that performs object rendering in a distributed fashion.
It is another object and advantage of this invention to provide a technique to distribute object rendering processing throughout a proxy network, and to not concentrate the object rendering processing in only specialized object rendering proxies.
It is a further object and advantage of this invention to provide a collaborative proxy network wherein object processing tasks, such as rendering, are distributed in an adaptive fashion based on, for example, dynamic loading characteristics of the proxy network.
The foregoing and other problems are overcome and the objects and advantages are realized by methods and apparatus in accordance with embodiments of this invention.
In accordance with the teachings of this invention a distributed object rendering method for a collaborative data network is disclosed. The data network, which may include the Internet, has attached computing nodes, including object requestor nodes, object source nodes, and intermediate nodes which may be proxy servers. The method can allow each participating proxy server, which may be referred to simply as a xe2x80x9cproxyxe2x80x9d and in the plural form as xe2x80x9cproxiesxe2x80x9d, to adapt to the dynamic load conditions of itself as well as proxies, as well as to the dynamic traffic conditions in the data network. The determination of which proxy or set of proxies is to perform object rendering and caching is based on a distributed, collaborative method that is adopted among the proxies. The criteria for such a method can include the bandwidth and current load of the network links among proxies, and/or the respective CPU usage of the proxies. If an object rendering can be staged, e.g., different resolution rendering, it can be performed by more than one of the proxies. The determination of which proxy performs which stage of the multistage rendering can also be adaptive to the dynamic load conditions, as well as network conditions.
As a result, a participating proxy, upon serving an object, first determines if object rendering processing is needed based on the client device type. If the object rendering processing is found to be required, then based on the requested object type and the collaborative information about other proxies in the network, the participating proxy can choose to (a) perform the complete object rendering by itself, (b) perform a partial rendering if the rendering process can be staged, or (c) do nothing and let another proxy perform the rendering task. The objective is to distribute the rendering processing throughout the proxy network, not just in the specialized object rendering proxies.
This invention thus provides a distributed, dynamic, hierarchical rendering method in a network comprised of interconnected computing nodes. The method includes steps of, at an object requesting node or at a proxy node coupled to the object requesting node, including with an object request certain meta-information describing the capabilities of the object requesting node (referred to herein as receiver hint information (RHI) or as requestor-specific capability information); at an intermediate node, receiving an object request and forwarding the request to another intermediate node (or to a source of the requested object), if the requested object is not available locally, while modifying the RHI to include information for specifying its local condition for providing the rendering service; otherwise, the intermediate node determines the required rendering, and invokes a selection function to determine, based on the RHI, what part or subset of the required rendering is to be carried out by the intermediate node. The intermediate node then performs the rendering and passes the rendered object to the requesting node. As a part of this invention another intermediate node that receives a partially rendered object invokes a selection function to determine, based on the RHI, what portion (or all) of the remaining required rendering is to be carried out by this intermediate node, and then performs the rendering and passes rendered object to the requesting node.
At an intermediate node having a less detailed version of the requested object the method includes such information in the RHI, forwards the request to another node, and at another intermediate node that has a more detailed version of the requested object, the node decides whether to return the more detailed version of the requested object, without further local rendering, or to instead perform some rendering and return a partially rendered object, or to instead return a completely rendered object.
The local condition information can include the loading and/or capacity of the node (such as CPU utilization), and can be a function of the network delay (from the requesting node). The local condition information can further include a type of rendering that can be performed at the node (which can depend on the software available at the node). The local condition information can further include the storage availability at the local node.
A selection method is provided for each intermediate node to decide dynamically and independently of other nodes what portion of the required rendering to perform locally using the RHI information. The selection method can include steps of (a) dividing a remaining rendering operation into steps; (b) selecting one or more rendering steps to be performed locally in order to optimize a given objective function, using the RHI information as an input parameter; and (c) performing the one or more rendering steps selected for the current node. The objective function can be to perform the rendering steps with the most bandwidth reduction first, and/or to perform the rendering steps so as to reduce load unbalancing among the remaining nodes on the path to the requesting client device node. The objective function can also be an estimated response time from this node to the requesting node, based on the RHI information.
Alternatively, the selection method can includes steps of (a) dividing the remaining rendering operation into steps; (b) assigning, in accordance with an assignment plan, the rendering steps to other nodes on a path to the requesting client device node to optimize the given objective function using the RHI information as the input parameter; and (c) performing the rendering step or steps that are assigned to the current node. It is also within the scope of the teaching of this invention to pass the assignment plan as meta information associated with the rendered object to a next node, which is then free to modify the assignment plan according to local considerations, such as CPU loading at the next node.
The rendered object and/or the received object can be passed to a cache manager for a caching consideration, such as a cost to produce the rendered object.
In general, different intermediate nodes can choose to use different selection functions for rendering, and each intermediate node may choose a different selection function depending upon the local condition of the node (e.g., CPU loading).
Each node may also periodically collect load statistic information from neighboring nodes, instead of including the information in the RHI associated with each request.